A. Field of the Invention.
This invention relates to machine vision, and more particularly, to methods and apparatus for creating a command framework for a machine vision system.
B. Background of the Invention.
In machine vision applications, a vision processor communicates with a host controller, computer, or other processor to automate such tasks as surface mounting of semiconductor devices. The communication between the two devices typically is in the form of commands the vision system is to perform and responses from the vision system regarding the results. The manufacturer of the vision processor usually defines a set of such commands that are included with the system. Commands might be defined for such functions as: acquiring an image; obtaining a frame buffer; inspecting the image in the frame buffer; displaying the results; and freeing the frame buffer.
Users of vision processing systems often need to customize or modify the vision processing features and may also develop new features for which new commands must be created. It may also be case that the vision processor may have several formats for such commands, for example, one format for commands received from the host controller, and a separate text- based command line interface for debugging purposes at the vision processor.
When a new command is added to the vision processor, a mapping between the command and the corresponding code invoked by that command in the vision processor is done, by the vision processor. One method of implementing this involves incorporating into the vision processor system a routine containing a series of if statements to do the mapping. In this approach, the mapping routine asks if the command is equal to a first command, and if not, a check is made for the next command, and so on, until a match is found. Each new command requires that the code in the mapping program be updated, recompiled, and re-linked into the vision processor in order to receive and handle a command from the host controller. Another approach uses a master lookup table which is indexed by the command name or command identifier. However, the entries still need to be entered into the table, and the table recompiled and relinked into the vision processor. Both of these prior approaches require not only that the command be compiled and linked into the vision processor, but also the recompilation and linking of either the mapping routine or the master lookup table.
In the field of computer networking in which different processors communicate with each other, remote procedure calls have been used to address a partially analogous situation, when one processor wishes to cause code to be executed at another processor location. In such a scheme, a packet of information is sent between the processors. Typically, such a packet contains information about the procedures being called and data arguments to be used by it.
In one such remote procedure call system the remote call mechanism provides a compiler that generates code that runs on both a client processor and a server processor. To continue the analogy to vision systems, the server would resemble the vision processor and the client the host. In this approach, three functions are used: register rpc, which is run on the server side; call rpc, which is run on the client side; and service run, also run on the server side.
In this system, a program runs in the background on the server, and at its startup, this program calls register rpc for each remote procedure call implemented in that server. Thus if five procedures are to be registered, there has to be code executed prior to calling service run that makes five calls to the register rpc function, one for each register rpc. Using this technique for the host or client side, it is necessary to specify the identifier of the remote machine, the procedure to be called and any arguments that must be passed to it.
In this approach, the information about the commands is distributed in several places throughout the server program and must be maintained accordingly. The series of calls to the register rpc function must be maintained and initiated. In such a system, a separate initialization step must be undertaken before the new procedures can be invoked.
Arguments and parameters passed to such procedures typically will need to be translated from the network representation to the representation used by the procedure in the server and that used b y the client. In one approach used by Sun Microsystems, these arguments are translated into and out of a format known as XDR for transmission over the network. In this scheme, the remote procedure can be invoked only with data in the XDR format.
Improvements in the method of adding new procedures in such networking applications have been accomplished in object-oriented remote procedure call systems using global objects or static initialization techniques to insert new procedures. In these systems, a server process contains a table indexed by an object identifier, and each entry points to a primary copy of the procedure object. When a new primary copy of an object is created, the constructor calls a routine to register the object mapping.
Improvements in the methods of translating to and from the XDR protocol have been described in which the translation of, or decoding to and from, an XDR protocol includes the use of object-oriented techniques, such as integrating a virtual model of an object-oriented data stream into input and output stream classes to format to an XDR protocol.
Exemplars and autonomous generic exemplars are other object-oriented design techniques known in the art which are also known to be applicable to creating a particular kind of object as selected by data.